A software program or application or the like (hereinafter, ‘program’) as developed for a computing device or the like may at times be required to be authenticated to another entity, either local to or remote from the computing device. For one example, a banking program interacting with a remote banking server may be required to be authenticated to the banking server as in fact being the banking program, and not some other program masquerading as the banking program for malicious or nefarious purposes. For another example, an audio rendering program interacting with a rights management program on the computing device may be required to be authenticated to the rights management program as in fact being the audio rendering program, and not some other program masquerading as the audio program for malicious or nefarious purposes.
As may be appreciated, program authentication is important in many other settings. For example: a local user needs assurance that he or she is typing a password into a legitimate program and not a program designed to steal the password; a platform running a program may demand an authentication token such as for example a certificate for the program before executing same; an organization may demand that each employee or other individual thereof use a computing device with an operating system with a particular approved configuration; such operating system may be configured to only load and execute drivers or programs that comply with a particular administrator policy; and the like.
As may be appreciated, many techniques exist for program authentication, and authentication data may be used for many different access control purposes. However, and significantly, authenticating a program itself is not always sufficient for purposes of determining whether to impart trust to the program. In particular, authenticating a program for purposes of imparting trust thereto should also include authenticating the setting within which the program resides, and should further include authenticating the underlying platform upon which the program operates. For example, the security status of an operating system running directly on hardware of a computing device is different than of such operating system running on a virtual machine which in turn runs directly on such hardware.
In particular, the security status of the operating system running on a virtual machine should take into consideration the fact that other operating systems running on the virtual machine may be able to examine and modify the operating system at issue and the flow of execution thereof. In such a situation, a determination of whether to impart trust to the operating system as issue should include a determination of whether to impart trust to the virtual machine. More generally, then, a determination of whether to impart trust to a program should include a determination of whether to impart trust to the execution environment of the program, since the execution environment will affect the running state of the program. As may be appreciate, the execution environment may be hardware, or may be established by another program, or both.
A need exists, then, for a method and mechanism by which a computer program can be authenticated both in terms of the program itself and the environment within which such program resides. More particularly, a need exists for such a method and mechanism whereby the authentication of the program itself includes a consideration of the setting and circumstances within which the program itself runs and the inputs that are provided to the program. Further, a need exists for such a method and mechanism whereby the authentication of the program includes an authentication of the underlying platform upon which the program operates.